Proposed operating systems will require the fast switching of logic circuits, such as subsystems within graphics processing hardware, or any other logic circuits that are used for differing functions or operations. However, switching the use of logic circuits from one function to another can result in the loss of data in portions of hardware pipelines or other logic.
A context switch occurs, for example, when one application or process is switched to use the same hardware that another application was using. Proposed operating systems may wish to frequently switch contexts such as rapidly switching between applications to draw new windows where the switching may require less time than it takes to properly flush an entire 3D pipeline. Proposed operating systems may send to a graphics processing circuit, for example, a list of different applications and hence different contexts to run in sequence which may require the use of a 3D graphics pipeline every few milliseconds for different contexts. As a result, the 3D graphics pipeline would have to draw window borders on a much more frequent basis than is currently done. Also, page faults for hardware using virtual memory can occur during a context switch. This will require time to supply missing memory data, during which time another application could otherwise be using the hardware. Different applications may use different page tables for each context so it is desirable to also store other state information such as the pointers to page tables as well as other information. Other problems related to context switches can occur if the requisite state information is not kept (such as keeping the state information of the programmed registers that are used by a 3D graphics pipeline to render objects or other information).
One technique for switching from one context to another is to flush all pending data out of a hardware pipeline prior to switching the logic for use with a new context. However, this can take large amounts of time. Other proposals known to the inventors include letting data pass through certain sections of a pipeline and adding additional buses and functional pathways to flush any pending work and associated state information and later feeding this data and state information into the front of the pipeline. However, this can be complicated to carry out and potentially costly.
A suggested technique for maintaining information in response to a context switch has been proposed that requires flushing the pipeline at certain stages that allow some stage of the pipeline to be completed (but not the entire pipeline) but this can result in partially rendered triangles since the pipeline may not have completed processing of the pixel through the entire pipeline. With such a proposal, the processing hardware can pick up where it left off but it can require additional logic in a scan converter to avoid re-rendering of pixels that were already rendered. If pixels are being blended it is also desirable not to repeat the blending. Consequently, it is desirable to keep track of where the pixel rendering is at a particular point in a pipeline.
There is also a kind of context switching that replicates state bits N times, where N is the number of potentially runnable contexts, but this can cost too much in extra hardware resources where either N or the number of bits is large. There are also interrupt-based software-driven save and restore techniques that use host processors, for example, to save state information and data and then restore the state information and data back into a portion of a pipeline or logic circuit. However, this can have high latency and can unnecessarily burden the host processor and reduce its processing bandwidth.
Accordingly, a need exists for a method and apparatus that can, among other things, facilitate context switching of logic circuits.